PNNI (Private Network-to-Network Interface) is a hierarchical, dynamic link-state routing protocol defined by the ATM (Asynchronous Transfer Mode) Forum for use in ATM networks. The hierarchy extension and the use of a single routing protocol at all levels of the hierarchy allow the support for large-scale ATM networks. A key feature of the protocol is the ability to cluster network nodes into manageable groups called “peer groups”. One node in each peer group serves as the “peer group leader” and represents that peer group as a single logical node (“logical group node” or LGN) in the next level up of the hierarchy. This concept is illustrated schematically in FIG. 1 of the accompanying drawings which shows a simple two-level hierarchical network. In the lowest level, level 1, of the hierarchy in this example, the nodes labeled AA1 to AA3, AB1 to AB3, AC1 and AC2 represent real network devices, such as switches, interconnected by links as shown. These nodes are clustered into three peer groups shown bounded by the broken lines in the figure. In each peer group, one node, shown shaded in the figure, is designated peer group leader. Each peer group leader is “elected” by a process specified by PNNI, and, in addition to its normal functions as a node within a peer group, serves to represent its peer group as a logical node in the next level up of the hierarchy. Thus, in the illustrated example, nodes AA1 to AA3 form a peer group which is represented, by peer group leader AA3, as logical node AA in level 2 of the hierarchy. Nodes AB1 to AB3 form a peer group which is represented, by peer group leader AB3, as logical node AB in level 2 of the hierarchy. Nodes AC1 and AC2 form a peer group which is represented, by peer group leader AC2, as logical node AC in level 2 of the hierarchy.
ATM is a source routing technology. To enable source route computation, the nodes must maintain information about the network topology. PNNI thus defines a system for the creation and distribution of topology data within a network. The topology data is defined by PNNI Topology State Elements (PTSE's) which are created and distributed by nodes so that each node can maintain a topology database which defines its view of the network. PTSE's include data relating to nodes, links and addresses (“reachable address prefixes”) which can be accessed by network devices. Reachable address prefixes may be node and/or end system addresses and may be summarized, representing a collection of individual addresses summarized by a single address prefix, or native, representing a single node or end system address. PTSE's are flooded among nodes in a peer group so that each peer group node has the same topology database and thus the same view of the network. In the next level up of the hierarchy, however, the peer group topology is abstracted into a single logical node as described above. The peer group leader generates PTSE's advertising addresses accessible within its child peer group and distributes these to its neighbors in the next level of the hierarchy, but the details of nodes and links within the peer group are lost. It is this topology abstraction that reduces the resources required to define very large networks. However, it is a consequence of this topology abstraction that the accessibility, or “connectivity”, of an address is known only within the peer group in which it originated. Thus, calls from outside a peer group to an address within the peer group may be instigated even though that address is in fact inaccessible, for example due to a link failure.
PNNI does define a “time-out” system for PTSE's whereby each PTSE is given a lifetime for which it is valid, normally one hour. A PTSE's originating node should “refresh” the PTSE every thirty minutes by redistributing the PTSE to its neighbors, so that the PTSE is again flooded through the peer group. Normally a PTSE may only be modified by its originating node (or in some cases by a proxy node acting on behalf of the originating node). However, if a PTSE's lifetime expires without the PTSE being refreshed, the PTSE is no longer considered valid topology information and is removed, or “flushed” from the topology database. That is, when a node detects that a PTSE's lifetime has expired, the PTSE is removed from that node's topology database and the expired PTSE is flooded (as an “empty” PTSE which indicates expiry of the topology element) throughout the peer group so that it is flushed from the peer group. Similarly, any PTSE created by the peer group leader defining that topology element will be flushed from the next level of the hierarchy, and so on throughout the network. Thus, if an address becomes inaccessible due to loss of connectivity within the peer group, expiry of the associated PTSE will eventually result in the address being flushed from the network (assuming connectivity is not restored in the meantime). Up to that time, however, call setup requests to that address may continue to be placed from outside the peer group, and will simply be rejected on reaching the peer group ingress.
Additional problems may arise with the existing scheme apart from that of unnecessary calls being placed to inaccessible addresses. For example, situations can arise where a device which has previously been connected as a node in one network configuration joins a new network configuration. Such a situation may result, for example, from changes in partitioning of peer groups in a network, or when a mobile node moves from one access point to another (Mobile PNNI). When connected in the new network configuration the node needs to adapt its peer group to the new situation. As part of the resulting database exchange process, the node may (and, in the case of a mobile node changing access points, invariably will) introduce reachable address prefixes from the hierarchy of its previous peer group. This can result in irrelevant addresses being advertised in the network, and presents the risk of routing via an invalid path.
As a further example, a serious problem can arise with the existing scheme in the case where a backup service is advertising the same reachable address as a primary service, for example a LECS (LAN Emulation Client Server). Should the primary server become isolated or stop functioning, all calls to this server from outside the peer group will continue to be routed to this server, and not to the backup server in another peer group, until the primary server address expires and is flushed from the network.